Änderungen

• 2026-10-10 Teilweise aktualisiert für WiSe 2026/27: Iteration und QS an D02 Projektmanagement und D04 Qualitätssicherung angepasst.

Teamprojekt Softwareentwicklung

Erinnerung: Spezifikationsdokument

• Vorabgabe: 2026-11-14

• Details und Bewertungskriterien im Moodle verlinkt

• Lasst das Dokument auch euren AGs zukommen und holt Feedback ein

• Finale Abgabe: 2026-11-27

Softwareentwicklungsprozesse

• Moodle: Software Engineering Best Practices

  • Zusammenfassung der Punkte letzter Woche

• Ähnliche Inhalte, anderer Blickwinkel

• Iterationen

• Anforderungen

• Qualitätssicherung

Iteration

• Grober Rahmen, kein fester Prozess

• 2 Wochen

• Treffen mit AG

• Treffen im Team: Planung, Aufgabenverteilung

• Anforderungen verwalten

• Software entwickeln

• Qualitätssicherung

• Laufende Software liefern

Treffen mit AG

• Abnahme von implementierten Anforderungen

  • Oft live Demo + abnicken

• Definition von weiteren Anforderungen

• Priorisierung von Anforderungen für die nächste Iteration

Treffen mit Gruppe

• Reflexion/Anpassung der Anforderungen

  • Zu groß? Schlechte Schätzung? Zu unklar?

  • Anpassungen mit AG absprechen

• Aufgabenverteilung

• Planung des AG treffen

• Reflexion was gut funktioniert, was besser funktionieren könnte

Protokolle

• Vor dem Treffen festlegen, wer Protokolliert.

• Notiert wichtiges:

  • Neue Anforderungen

  • Was ist dem AG wichtig

  • Absprachen/Entscheidungen

  • Punkte die auf später verschoben wurden

Anforderungen

(siehe auch D03 Anforderungen)

Anforderungen

• „Vertrag zwischen AG und Gruppe“

• Werden vom Team erstellt, vom AG abgenommen

  • Das ganze Team sammelt Anforderungen

  • Keine Trennung zwischen

    • „Entwickler:innen“ und

    • „Menschen die Anforderungen sammeln“.

• Basieren auf Input vom AG, von eventuellen Nutzern, oder eigeninitiativ.

• Kleinteilig genug, damit mehrere pro Iteration bearbeitet werden können

• Mehrwert für die Projektziele

• Achtet auch auf nicht-funktionale Anforderungen!

  • Sicherheitsstandards

  • Laufzeitumgebung

Anforderungsmanagement

• Anforderungen müssen dokumentiert sein

  • User Stories

  • Issues

  • Tasks

  • Cards

  • Prototypen/Mockups

• Nutzt Formate die mit euren Werkzeugen funktionieren!

Struktur von Anforderungen

• Unbearbeitet:

  • Deskriptor

  • prüfbare Akzeptanzkriterien

  • Aufwandsschätzung

• Erledigt:

  • in Iteration X

  • Aufwand in Stunden pro Teammitglied

  • Von AG abgenommen

Beispiel 2

Anforderung 101: Nutzersymbole

• Akzeptanzkriterium: Die Spieler werden auf der UI mit farblich unterscheidbaren Symbolen dargestellt.

• Geschätzer Aufwand: 1 Punkt.

• Tatsächlicher Zeitaufwand: (noch offen)

Story Points

• Abstrakte Aufwandsschätzung

• Punkte:

  • 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, $\infty$, ☕, ?

• Relativ zu anderen Anforderungen

Pointing Poker

• Jeder schätzt für sich

• Dann wird Konsensus gebildet

  • Diskutiert abweichende Meinungen

• https://www.pointingpoker.com/

• https://pokerplanning.org/

Velocity

• Im Nachhinein

• Wie viele Stunden pro Story Point?

• (Wie viele Story Points pro Iteration?)

Iterationszyklus

• Neue Version der Software

  • Erfüllte Akzeptanzkriterien?

  • Velocity der erfüllten Anforderungen?

  • Gesamtstorypoints in dieser Iteration?

• Neue Anforderungen?

• Änderung an existierenden Anforderungen?

• Prioritäten für existierende Anforderungen?

• Welche Anforderungen werden in dieser Iteration bearbeitet?

  • Arbeitet wichtige einfache Anforderungen zuerst ab

Qualitätssicherung

(siehe auch D04 Qualitätssicherung)

QS im WiSe 2026

• Vorgegeben:

  • Code Reviews

  • Tests

  • Pair Programming

• Systematisch, durchführbar, überprüfbar

• TB hat Einsicht in euren QS-Prozess

• Zusätzliche Wünsche der AGs: siehe Qualitätssicherungsziele

Code Reviews

• Reviewer hat Code nicht geschrieben.

• Jeder Code wird gereviewt.

  • Wann? (z.B. vor Akzeptanz)

  • Checkliste.

• Verteilt Wissen im Team

• Code-Analyse-Tools helfen

Pair & Group Programming

• Dient der Wissensweitergabe

• Konzept: Arbeiten mit kurzen Kommunikationswegen

• Arbeitet gemeinsam im gleichen Raum (auch virtuell!)

• Klassisch: Eine steuert, beide denken

• Auch möglich:

  • Alle arbeiten an verschiedenen Dingen.

  • Bei aufkommenden Fragen werden dynamisch Gruppen gebildet.

  • Group Programming: das ganze Team an einer Aufgabe

• Gezielt bei komplexeren Problemen einsetzen

Tests

• Manuell

  • Checklisten!

  • Prüfbarkeit!

• Automatisch

  • Unit

  • Integration

  • Continuous Integration

• Wie ist der Prozess bei Testfehlern?

Fragen?